Visual reconstruction of traffic incident based on sensor device data

ABSTRACT

A system, a method, and a computer program product for providing a recreation of an event are disclosed. A plurality of data is received from a plurality of sources of information. The plurality of data describes an event. Each data in the plurality of data has a different format. Each data in the plurality of data is converted into a predetermined format. The converted received plurality of data is combined. Based on the combined converted received data, a report describing a recreation of the event is generated. The generated report is transmitted for display on at least one user interface.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/913,650, filed Jun. 26, 2020, entitled “Visual Reconstruction ofTraffic Incident Based on Sensor Device Data,” which is a continuationof U.S. patent application Ser. No. 14/980,707, filed Dec. 28, 2015,entitled “Visual Reconstruction of Traffic Incident Based on SensorDevice Data,” and claims priority to U.S. Provisional Patent ApplicationNo. 62/099,042 to Melissa O'Kane, filed Dec. 31, 2014 and entitled“Visual Reconstruction of Traffic Incident Based on Sensor Device Data.”Each of these applications is incorporated by reference in its entiretyherein.

TECHNICAL FIELD

In some implementations, the current subject matter generally relates todata processing and, in particular, to visual reconstruction of atraffic incident based on a sensor data.

BACKGROUND

Customers may insure property and/or items (e.g., vehicles, belongings,etc.) with an insurance provider. In some cases, if an insured item isdamaged and/or destroyed, a customer may submit an insurance claim tothe insurance provider so that a claims adjuster for the insuranceprovider can view the damage to the insured item to determine anyliability with respect to the customer. For example, if an insuredvehicle is damaged in a traffic incident (e.g., an accident), thecustomer may submit the insurance claim with information relating to theaccident, including information relating to the condition of the damagedvehicle.

In certain instances, the insurance claim may be incomplete or containirrelevant information relating to the damaged vehicle or accident. Forexample, it may be difficult to determine liability of the customer dueto inadequate information, although there may be substantial damage tothe insured vehicle. As such, any unnecessary delay or incompleteunderstanding of the traffic incident can adversely impact thecustomer's experience through the insurance claims process.

SUMMARY

In some implementations, the current subject matter relates to acomputer implemented method for recreating an event. The method caninclude receiving a plurality of data from a plurality of sources ofinformation, the plurality of data describing an event, each data in theplurality of data having a different format, converting each data in theplurality of data into a predetermined format and combining theconverted received plurality of data, generating, based on the combinedconverted received data, a report describing a recreation of the event;and transmitting the generated report for display on at least one userinterface. At least one of the receiving, the converting, thegenerating, and the transmitting can be performed by at least oneprocessor of at least one computing system.

In some implementations, the current subject matter can include one ormore of the following optional features. The plurality of sources caninclude a plurality of sensors communicatively coupled to the at leastone computing system (e.g., rendering system 102). The plurality ofsensors can detect and record information about the event.

In some implementations, the data can include at least one of thefollowing: a video data, an audio data, a text data, a photographicdata, and any combination thereof.

In some implementations, the generated report can be transmitted fordisplay using a first user interface associated with a first user device(e.g., user device 104) and for display using a second user interfaceassociated with a second user device (e.g., user device 106). The firstand second user devices can be communicatively coupled to the at leastone computing system using a network.

In some implementations, the method 800 can further include receivingchanges to the generated report from the second device, generating,based on the received changes, a new report and transmitting the newreport to the first user device and the second user device, receiving aconfirmation, from the second device, indicating that the new report hasno changes, and transmitting the confirmation to the first device.

In some implementations, the report can include at least one of thefollowing: a data describing the event, a video illustrating the event,an audio describing the event, an animation illustrating the event, anarrative textual data describing the event, and any combinationthereof.

In some implementations, the event can be a vehicular accident. In thatcase, the plurality of sensors can include at least one of thefollowing: a vehicle blackbox sensor, a mobile device, a vehicle onboardusage-based insurance enable device, and a vehicle onboard sensor. Thegenerated report can be transmitted to a claimant user device fordisplay on a user interface associated with the claimant user device,wherein the claimant user device is used to record data describing thevehicular accident. The claimant user device can be communicativelycoupled to the computing system for submission of at least one insuranceclaim as a result of the vehicular accident. A claims adjuster devicecan receive the generated report for processing of the insurance claim.

Non-transitory computer program products (i.e., physically embodiedcomputer program products) are also described that store instructions,which when executed by one or more data processors of one or morecomputing systems, causes at least one data processor to performoperations herein. Similarly, computer systems are also described thatmay include one or more data processors and memory coupled to the one ormore data processors. The memory may temporarily or permanently storeinstructions that cause at least one processor to perform one or more ofthe operations described herein. In addition, methods can be implementedby one or more data processors either within a single computing systemor distributed among two or more computing systems. Such computingsystems can be connected and can exchange data and/or commands or otherinstructions or the like via one or more connections, including but notlimited to a connection over a network (e.g., the Internet, a wirelesswide area network, a local area network, a wide area network, a wirednetwork, or the like), via a direct connection between one or more ofthe multiple computing systems, etc.

The details of one or more variations of the subject matter describedherein are set forth in the accompanying drawings and the descriptionbelow. Other features and advantages of the subject matter describedherein will be apparent from the description and drawings, and from theclaims.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, show certain aspects of the subject matterdisclosed herein and, together with the description, help explain someof the principles associated with the disclosed implementations. In thedrawings,

FIG. 1 illustrates an exemplary system for recreating an event,according to some implementations of the current subject matter;

FIG. 2 illustrates an exemplary system for recreating an event,according to some implementations of the current subject matter;

FIG. 3 illustrates an exemplary process for recreating an event,according to some implementations of the current subject matter;

FIG. 4 illustrates an exemplary user interface that can be displayed ona claimant user device, according to some implementations of the currentsubject matter;

FIG. 5 illustrates an exemplary user interface that can be displayed onthe claimant user device and that can allow the user to provideadditional information, according to some implementations of the currentsubject matter;

FIG. 6 illustrates an exemplary user interface showing various frames ofthe animation, according to some implementations of the current subjectmatter;

FIG. 7 illustrates an exemplary system, according to someimplementations of the current subject matter; and

FIG. 8 illustrates an exemplary method, according to someimplementations of the current subject matter.

DETAILED DESCRIPTION

In some implementations, the current subject matter relates torecreating an event, including providing a graphical and informationrepresentation of the circumstances associated with the event along withany details that may be pertinent to the understanding of whattranspired during such event. The event can include at least one of thefollowing: a traffic accident, a property damage, a personal injury, acrime, and/or any other event. The representation of the event can bebased on at least one of the following: data describing the event, audioand/or video information associated with the event, written narrativeinformation, information obtained from third party sources (e.g., theInternet, news sources, etc.) and/or any other information. Theinformation can be obtained from one or more participants of the event,observers of the event, third parties, etc. The information can betransmitted using wired, wireline, and/or wireless networks, local areanetworks (“LAN”), metropolitan area networks (“MAN”), wide area networks(“WAN”), the Internet, and/or any other networks. In some exemplaryimplementations, reconstruction of the event can be useful during aclaim process that is designed to provide a monetary benefit to a holderof an insurance policy. For illustrative, non- limiting purposes only,the following discussion is presented in connection with such insuranceclaims process, where the event is an automotive accident and theinsurance claim process relates to making a claim by a holder of anautomotive insurance as a result of such accident. However, as can beunderstood, the current subject matter can be applicable toreconstruction of any event for any purpose.

In some implementations, as part of an insurance claims process, thecurrent subject matter can render data for displaying a representationof a traffic incident recreation on a client computing device. Thecurrent subject matter can reconstruct a vehicular accident using datafrom one or more sensor devices of one or more client computing devices(e.g., accelerometer, gyroscope, camera, audio capture element, GPS,etc.) including data from a vehicle on-board computer and/or data fromusage-based insurance (“UBI”) enabled devices. The representation of thetraffic incident recreation can include an animation in two-dimensionaland/or three-dimensional space. The traffic incident recreation can besent to a claims adjuster handling the insurance claim.

The current subject matter can provide several advantages including useof sensor data captured at the time of an accident to determinecontextual information relating to the cause and/or result of theaccident, enabling a user or insurance provider agent (e.g., the claimsadjuster) to view an animation of the vehicular accident to add contextbefore and after the accident, facilitating processing of an insuranceclaim by the insurance provider and/or third parties associated with theaccident, and/or promoting cost conservation by enabling the insuranceprovider to cut down on investigation costs.

In some implementations, the current subject matter can provide arendering of a visual representation of a traffic incident recreationfor display to a user. The current subject matter can be implemented onone or more computing devices (e.g., servers) in communication with anetwork. The current subject matter can be associated with an insuranceplatform provided by an insurance company and can include one or moreserver machines affiliated with the insurance company. Further, thecurrent subject matter can belong to an insurance company and/or anotherparty associated with an insurer. In some implementations, the currentsubject matter can be implemented on a desktop computer, a laptop, amobile device, a tablet, a mobile telephone, a smartphone, and/or anyother computing device.

In some implementations, the current subject matter can becommunicatively coupled to one or more client computing devices over anetwork. The client computing devices can be associated with a user orcustomer (e.g., policyholder). The client computing device can be amobile device that can include at least one of the following: asmartphone, a mobile telephone, a tablet, a laptop, a desktop computer,a camera device, a UBI-enabled device, and/or any other device, and/orany combination thereof, capable of communicating with other devices viathe network.

In some implementations, the current subject matter can include asoftware application running on the mobile device that can accessvarious capabilities of the mobile device and/or capabilities of devicesin communication with the mobile device. For example, the applicationcan obtain sensor data from one or more sensor devices located on themobile device and/or located on one or more client computing devices incommunication with the mobile device. The application can access one ormore cameras on the mobile device (e.g., a front-facing camera and/or arear-facing camera), microphones on the mobile device, and/or othersensor devices. The one or more sensor devices can include an imagecapture element (e.g., a camera), an audio capture element (e.g.,microphone), a gyroscope, an accelerometer, infrared sensors, and/or aglobal positioning system.

The sensor data can include audio and/or video content that can beprovided by a camera. The audio/video content can provide the insuranceprovider with a record of events from the viewpoint of the mobile devicelocated in the insured vehicle in the event that a traffic incident(e.g., an accident) occurs and/or any other time. The sensor data canalso include location information from a global positioning system(“GPS”) device that can be integrated into the mobile device and/or incommunication with the mobile device. The location information (e.g.,GPS coordinates) and/or any other data obtained by the GPS device can beused to provide the insurance provider with additional informationassociated with the traffic incident.

In some implementations, the sensor devices can include at least one ofthe following: a recording device located on-board of a vehicle that canbe communicatively coupled to the system. The recording device on-boardthe vehicle can be accessed through a communication link (e.g., UBI).The on-board vehicle recording device can record data associated withactions performed as part of the operation of the vehicle. For example,the recording data can include information relating to the velocity ofthe vehicle, location of the vehicle, weather and traffic conditions(via a third party service provider), zoning information, throttleposition, torque information, fault codes, messages, vehicle serviceinformation, and/or any other information.

In some implementations, the user (and/or policyholder) can be asked tosubmit login credentials for an account associated with the user. Theaccount can be viewed and/or accessed by the user via the softwareapplication and/or a website portal on the network. The current subjectmatter can cause a prompt to be displayed on a display screen of themobile device. For example, the prompt can include fields to enter anemail address (or username) including a password for the account. Theprompt can be part of a splash page provided for display with thesoftware application and/or the website portal. The splash page caninclude information relating to legal disclaimers and/or additionalinformation relating to the insurance provider. Upon login, the currentsubject matter can also display the customer's insurance policyinformation.

The software application can facilitate receipt of the obtained sensordata for reconstructing a vehicular accident as an animation. Theapplication can be installed on the mobile device that can includeinstructions (and/or prompts) to guide the user to upload the sensordata and/or add additional information relating to the insurance claim.The software application can include a prompt requesting permission fromthe user to upload the sensor data. In some implementations, thesoftware application can include a status page including an animationthat represents real-time feedback of the uploading process. Thesoftware application can include an additional splash page providing anindication that the upload to the system was successful. The uploadresult can include a summary of information relating to the uploadedsensor data. The software application can include a prompt requestingthe user to verify (and/or confirm) the uploaded sensor data. The usercan be provided with an option to edit (and/or change) any of theuploaded data and/or proceed to the next step in the process. In someimplementations, the software application can pull the sensor dataautomatically from the sensor devices. In alternate implementations, thesensor devices can automatically send the sensor data to theapplication.

In some implementations, the current subject matter can generaterendered data based on the sensor data uploaded from the application todisplay a visual representation of a traffic incident recreation on adisplay screen of the mobile device and/or a display associated with theclaims adjuster. The uploaded sensor data can include image information,audio/video information, location information, and/or any otherinformation. The current subject matter can use one or more algorithmsrelated to image processing, voice recognition processing, orientationprocessing and/or navigation processing to determine features includedin the sensor data. The features can include spatial and/or temporalinformation to recreate the visual representation of the reconstructedtraffic incident.

The traffic incident recreation can include mapping information and/orobject information in two-dimensional space or three-dimensional space,and/or a combination thereof For example, the traffic incidentrecreation can show as time-lapse animation one or more events leadingup to the traffic incident, the traffic incident event, and/or one ormore events following the traffic incident. The sensor data provided inthe upload can facilitate in recreating the amount of damage caused tothe insured vehicle and/or other third party vehicles involved.

In addition, the sensor data can facilitate in defining the rate ofmovement of the insured vehicle including the amount of force generatedby the traffic incident. The traffic incident recreation can assist theclaims adjuster in determining a root cause of the accident, the partieslikely to have liability implications, and/or the amount of damagedsuffered by each of the parties involved.

In some implementations, the current subject matter can send therendered data to a client computing device associated with a requestinguser to verify the rendered data. The current subject matter can requestthe user to confirm the accuracy of the uploaded sensor data. Thecurrent subject matter can request (and/or prompt) the user to addadditional information to facilitate the rendering process. The currentsubject matter can also request the user to edit any existinginformation included in the uploaded sensor data.

The software application can include a page requesting the user tosubmit additional information relevant to the traffic incident. Forexample, the page can include a prompt to record audio data fromobserving witnesses, a prompt to enter witness information, a prompt tosubmit a drawing (or sketch) of the traffic incident, a prompt to submitadditional notes relating to the traffic incident, and/or a prompt tosubmit a photo and/or audio/video relating to the traffic incident. Thesoftware application can communicate with one or more servers to processthe uploaded data and/or render data for visual display of the trafficincident recreation. The software application can interface with acommunication channel to send (and/or upload) the received data. Thesoftware application can include a page providing real-time feedback ofthe transmission of the data to the system.

In some implementations, the current subject matter can send therendered data to a client computing device associated with a claimsadjuster. A similar notification can be sent to the claims adjuster toadvise the claims adjuster that the traffic incident recreation isavailable for viewing. In some implementations, the notification to theclaims adjuster can include an indication that the traffic incidentrecreation is subject to final confirmation by the user. The claimsadjuster can be associated with the insurance provider, an entity thatis part of the system or part of a different machine-implemented systemin other aspects of the subject technology.

In some implementations, the current subject matter can receive anindication that the requesting user verified the rendered data. Thecurrent subject matter can send an acknowledgment back to theapplication to indicate that the verification of the uploaded data iscomplete. Further, current subject matter can send a follow-upnotification to the claims adjuster that the uploaded data has beenconfirmed by the user.

In some implementations, the current subject matter can send anotification to the application that can include an indication that therendered data is complete and available for viewing. The notificationcan cause a prompt to be displayed to enable the user to select to viewthe traffic incident recreation. The notification can include a promptto save the traffic incident recreation in a memory of the mobile deviceor other memory communicatively coupled to the mobile device (e.g.,cloud storage, flash drive). The notification can also cause a prompt tobe displayed to enable the user to share the traffic incident recreationwith other users associated with the user over a network (e.g., a socialnetwork).

In some implementations, the rendered data can be stored in one or morerepositories associated with the insurance provider. In this regard, therendered data can be associated with an insurance claim being processedby the insurance provider. The current subject matter can store therendered data (or traffic incident recreation) at the server for aperiod of time (e.g., I week). The rendered data can be logged andattached to an existing insurance claim with the consent of thecustomer. After the period of time expires, the rendered data can bedeleted. By deleting the rendered data after a period of time, thecurrent subject matter can help reduce privacy concerns associated withkeeping the rendered data indefinitely or for longer period of time.

FIG. 1 illustrates an exemplary system 100 for recreating an event,according to some implementations of the current subject matter. Thesystem 100 can include a rendering system 102, a first user (e.g., aclaimant) device 104, a second user (e.g., a claims adjuster) device106, and a plurality of sensors 110 a, 110 b, 110 n. The renderingsystem 102 can include one or more servers that can have one or moreprocessors 112, one or more graphics processors 114, one or more datastorage components 116, communication capabilities (e.g., wired,wireline, and/or wireless), as well as any other components, and/or anycombination thereof. The rendering system 102 can be communicativelycoupled to the first user device 104 and the second user device 106. Therendering system 102 and the devices 104, 106 can be communicativelycoupled using a wired, wireline, and/or wireless network, which caninclude at least one of the following: a virtual network, Internet,intranet, extranet, MAN, WAN, LAN, and/or any combination thereof.

The devices 104, 106 can include at least one of the following: a mobiletelephone, a mobile device, a smartphone, a tablet, a desktop computer,a laptop, a personal digital assistant (“PDA”), a scanner, a monitor,and/or any other device and/or any combination thereof. The devices 104,106 can be any combination of software and/or hardware and can includeone or more software applications being executed on the devices 104, 106that can allow communication and processing of the data exchangedbetween the devices 104, 106, the rendering system 102, and the sensors110.

The rendering system 102 can be communicatively coupled with one or moresensors 110 via one or more communication networks 108. The network 108can be a wired, wireline, and/or wireless network, which can include atleast one of the following: a virtual network, Internet, intranet,extranet, MAN, WAN, LAN, and/or any combination thereof. The sensors 110can be used to gather various data related to the event for processingand recreation by the rendering system 102. The sensors 110 can collectat least one of the following: an audio data, a video data, aphotographic data, global positioning system coordinates, data relatedto the participants of the event, data related to the observers of theevent, textual data (e.g., written narrative information, a witnessstatement, etc.), data/information obtained from third party sources 118(e.g., news sources, government agencies, etc.) and/or any otherdata/information, and/or any information thereof. The data/informationcan be obtained automatically, entered manually, obtained as a result ofa trigger associated with the event (e.g., preceding the event,occurring during and/or after the event, etc.), as a result of a requestmade (e.g., by the rendering system 102, and/or any devices 104, 106),etc.

In some implementations, the rendering system 102, using one or more ofits processors 112, 114, can receive the data from the sensors 110and/or the user device 104 for processing. The processors 112, 114 cananalyze received data and generate one or more reports, which can bedisplayed on one or more user interfaces on the devices 104, 106 and/orany other devices that may be communicatively coupled to the renderingsystem 102. The reports can be transmitted over communication networksconnecting the devices 104, 106 to the rendering system 102.

To generate a report based on the received information, the renderingsystem 102 can recognize the information and/or data that are beingreceived from the sensors 110 and/or devices 104, 106 and/or any otherthird party sources. The rendering system 102 can recognizeinformation/data (e.g., data packets) based on the data identifierscontained in the transmitted information/data. In some exemplaryimplementations, the rendering system 102 can perform a shallow packetinspection and a deep packet inspection of data packets that it receivesto extract various information, which can be used to determine theorigin of the information/data, its content, and/or any otherinformation that the rendering system 102 can use for any furtherprocessing. Based on the extracted information/data, the renderingsystem 102 can determine how to assemble the information and/or create areport for transmission to the devices 104, 106.

The rendering system 102 can further determine that in order to generatea report, it needs additional information. To obtain such additionalinformation, the rendering system 102 can forward a request (e.g., ahypertext transfer protocol (“HTTP”) request, etc.) to the sensors 110,devices 104, 106, and/or any other third party sources, to provide suchinformation. The rendering system 102 can also determine which thesensors 110, devices 104, 106, and/or any other third party sources 118can possess the additional information and, upon such determination, therendering system 102 can appropriately format its request for additionalinformation and forward same to the determined/selected source.Alternatively, the rendering system 102 can broadcast its request foradditional information to all available sources of information.

Once the information/data and/or any additional information/data arereceived, the rendering system 102 can combine the information/data intothe report. The rendering system 102 can use one or more templates tocompile information together and organize it into a report. Thetemplates can be specific to a particular event, for which the renderingsystem 102 can generate a report, and can include a plurality of datafields that can be populated with the received information/data. Forexample, if the event is a vehicular accident, the rendering system 102can select a vehicular accident report template, which can include atleast one of the following data fields: vehicle information, driverinformation, speed of the vehicle involved in the accident, location ofthe accident, time of the accident, weather at the time of the accident,traffic level in the area of the accident, presence of construction inthe area of the accident, throttle position at the time of (and/or priorto, after) the accident, vehicle torque at the time of (and/or prior to,after) the accident, trouble codes, etc., and/or any combinationthereof. If the event relates to the property damage, the renderingsystem can select a property damage report template, which can includeat least one of the following data fields: property address, ownerinformation, age of the property, type of damage (e.g., flood, fire,etc.), weather conditions at the time of (and/or prior to, after) theoccurrence of damage, etc., and/or any combination thereof. In someimplementations, the rendering system 102 can create templates fordifferent types of events to accommodate generation of reports. In someimplementations, the rendering system 102 can generate reports withoutuse of templates and provide such reports to devices 104, 106 in freeform.

In some implementations, the sensors 110 can detect and/or gatherinformation/data relating to and depending on a type of the event. Thesensors 110 can be communicatively coupled to the devices 104, 106 andcan receive and/or transmit information from and/or to the devices 104,106. The sensors 110 can be used to detect and/or obtain variousinformation that can depend on the event. Once the information isobtained by the sensors 110, the sensors 110 can transmit theinformation/data to the rendering system 102 and/or devices 104, 106.Upon receipt of the information/data, the rendering system 102 canformat the received information/data for further processing. Theinformation/data can be transmitted by the sensors 110 in asensor-native format and/or can format the information/data to apre-determined format prior to transmission to the rendering system 102and/or devices 104, 106.

In some implementations, the sensors 110 can be activated as a result ofthe occurrence of the event and record information/data. Alternatively,the sensors 110 can record information a predetermined amount of timeprior to the time of the event, during the event and/or a predeterminedamount of time after the occurrence of the event. For example, if theevent is a vehicular accident, the sensors 110 can recordinformation/data about what happened prior to the accident (e.g., 15minutes prior to the accident, the vehicle was driving at 55 mph on athree-lane highway, traffic was moving smoothly, no constructionpresent, weather was calm and sunny at 68 degrees F., etc.), whathappened at the time and/or during the accident (e.g., the vehicle hitanother vehicle driving at 45 mph, heavy rain began to fall, etc.), andwhat happened after the accident (e.g., another vehicle hit the drivers'side 30 seconds after the occurrence of the initial accident, etc.). Insome implementations, the sensors 110 can continuously recordinformation without being limited to any particular period of time.

In an exemplary implementation where the event is a vehicular accident,the sensors 110 can include at least one of the following: a speedsensor, a fuel sensor, a torque sensor, a rear-view camera, a brakesensor, a weather sensor, a tire pressure sensor, and/or any othervehicle sensor. Additionally, the sensor 110 can include a detectordevice that can be plugged into vehicle diagnostic port for the purposesof gathering information, a sensory sticker placed on a windshield of oranywhere on the vehicle, and/or any other sensory device. Additionally,the driver's communications device (e.g., a mobile telephone, asmartphone, a tablet, a personal computer, a laptop, etc.) can be usedas one of the sensors 110 that can provide information to the renderingsystem 102 and/or communicate with one or more of the other sensors 110.The driver's communications device can also be the device 106. Thedevice 106 can be used to record video, audio, a written narrativeand/or any other information about the event. For example, a partyand/or a witness to the vehicular accident can be interviewed using thedevice 106, the driver (e.g., an insured, a claimant, etc.) of thevehicle can record a statement about the accident (which can include avideo, an audio, a photograph, a written (typed and/or handwritten)narrative, etc.) using the device 106, and/or any other information/datacan be recorded.

Once the information/data about the event is gathered from the sensors110, the device 106 and/or a third party source 118, and/or from anyother source, it can be forwarded to the rendering system 102 forprocessing and generation of a report. In some implementations, thedevice 106 can be provided with a software application (e.g., a mobileapplication that can be downloaded to the device 106) having one or moreuser interfaces, which the user can use to access the application andsubmit data relating to the event. In order to submit information, theuser can be prompted to enter login credentials to access the softwareapplication, submit information/data, and/or view any reports that mayhave been generated by and forwarded to the device 106 the renderingsystem 102. In the exemplary implementation of an insurance claimrelating to a vehicular accident, the user can also use the softwareapplication to edit the information contained in the report generated bythe rendering system 102 and/or verify that the report is accurate aswell as submit an insurance claim to an insurance company's claimsadjuster (e.g., device 104).

FIG. 2 illustrates an exemplary system 200 for recreating an event,according to some implementations of the current subject matter. Forease of illustration only, the system 200 will be discussed inconnection with a vehicular accident. The system 200 can include amobile application 202, a rendering system 204, a claimant user device206, and a claims adjuster device 208. The components 202-208 can becommunicatively coupled using a network, which can include at least oneof the following: a wired network, a wireless network, a virtualnetwork, Internet, intranet, extranet, MAN, WAN, LAN, and/or anycombination thereof. The process can begin by uploading variousinformation from vehicle sensors, which can include at least one of thefollowing: a vehicle blackbox, a mobile device, a vehicle onboard UBI,vehicle onboard sensors, etc., as well as information recorded by thedriver of the vehicle, which can include at least one of the following:a video, a photograph, an audio, witness statement(s), etc. Theinformation can be uploaded using the application 202 (which can bedownloaded on the driver's mobile device and can be the same as theclaimant user device 206) upon entry of appropriate login credentials bythe driver. The login credentials can be associated with a particularautomobile insurance police held by an insurance company (which theclaims adjuster device 208 can represent) covering the vehicle. Once theinformation has been submitted through the application 202, theapplication 202 can send the uploaded information to the renderingsystem 204 (similar to the rendering system 102 shown in FIG. 1 ).

The rendering system 204 can then render the received information andrender it into recreation of a vehicular accident. The rendering system204 can use its data and graphic processing components (e.g., CPU 112,GPU 114, database 116, etc. as shown in FIG. 1 ) to process and generatea recreation of the accident. Once the recreation is complete, therecreated incident data in the form of a report can be transmitted tothe claimant user device 206 for display and/or editing and/orconfirming that the information contained in the report is correct. Thereport can also be forwarded to the claims adjuster device 208 with anindication that the report is not a final report and is pendingapproval/edits by the claimant user device 206.

Using the claimant user device 206, the user of the device can makechanges to the report and/or submit additional information. The reportcan be presented on the claimant user device 206 can be presented withthe report using one or more user interfaces. An exemplary userinterface 400 that can be displayed on the claimant user device 206 isshown in FIG. 4 . The report indicates contains various fields that showinformation associated with the accident and provides the user with anopportunity to “EDIT” the report or “ACCEPT” the report as presented.Should the user of the claimant user device 206 determines that some orall information is incorrect and/or additional information can be added,the user can choose to “EDIT” the report and can be prompted to anotheruser interface that can allow the user to make changes/submit additionalinformation.

FIG. 5 illustrates an exemplary user interface 500 that can be displayedon the claimant user device 206 and that can allow the user to provideadditional information. The user interface 500 can be presented to theuser prior to, during, and/or after sending information about theaccident to the rendering system 204. The user can be provided with atleast one of the following exemplary options: “Record Witness Audio”,“Enter Witness Information”, “Submit Sketch of Incident”, “SubmitStatement”, “Submit Video/Picture,” and/or any other options forchanging and/or adding information to the report. The user can click ortouch one of these options to submit requisite information/data. Thechanges/additional data can be transmitted to the rendering system 204.The system 204 can process the changes and generate a revised and/or newreport and transmit it back to the claimant user device 206 and/orclaims adjuster device 208. This process can be repeated until the userhas no further changes and/or new information to submit.

Referring back to FIG. 2 , once the user of the claimant user device 206has no further changes and/or no additional information to submit to therendering system 204, the user can indicate that the report generated bythe rendering system 204 is accurate and transmit a confirmation (e.g.,touching “CONFIRM” on the device 206, sending an email, a text message,a multi-media message, etc.) to the rendering system 204. Once therendering system 204 receives confirmation from the claimant user device206, the rendering system 204 can store the final report (e.g., in thedatabase 116 as shown in FIG. 1 ) and append the report to an insuranceclaim being made in connection with the accident. The rendering system204 can also send the final report to the claims adjuster device 208 forviewing and/or processing in connection with the insurance claim.Alternatively, the rendering system 204 can send a notification (e.g.,an email, a text message, etc. and/or any other type of alert) to thedevice 208 indicating that the final report is available for review.

In some implementations, the rendering system 204 can also create ananimation of the accident using its graphic processing capabilities(e.g., a GPU 114 as shown in FIG. 1 ). An exemplary user interface 600illustrating various frames of the animation is shown in FIG. 6 . Theanimation can be presented in separate picture frames and/or as acontinuous video. The animation can be also transmitted and/or can bemade available for access from a server to the claimant user device 206and/or claims adjuster device 208.

Using the report, animation, and/or any other information generated bythe rendering system 204, the user (e.g., a claims adjuster) of theclaims adjuster device 208 can process the insurance claim to determineliability, payouts, etc. The system 200 can allow for more accuraterecreation of the accidents and expedient processing of insuranceclaims.

FIG. 3 illustrates an exemplary process 300 for recreating an event,according to some implementations of the current subject matter. Theprocess 300 can be performed by the system 100 shown in FIG. 1 and/or bythe system 200 shown in FIG. 2 . At 302, event data can be received fromat least one sensor (e.g., sensor 110 as shown in FIG. 1 ). The receivedevent data can be received by the rendering system (e.g., system 102 asshown in FIG. 1 ). The rendering system can process the received data,at 304. This can be accomplished using various data processors, graphicprocessors, databases, etc. Based on the received data, the renderingsystem can recreate the event (i.e., what happened during the event,prior to the event, and/or subsequent to the event), at 306. Therecreation of the event can be compiled into a report, which can betransmitted to a first and second user devices (e.g., devices 104, 106as shown in FIG. 1 ), at 308. At 310, a determination can be made as towhether or not the report generated by the rendering system is correct.The determination can be performed by the second user device (e.g.,device 106) and transmitted to the rendering system. If the data is notcorrect, the second user device can be used to correct/add the reportand the corrected/added information can be transmitted to the renderingsystem, at 312. If it is correct, then the rendering system can receivean appropriate confirmation from the second user device and transmit anindication the generated report is correct, as having been confirmed bythe second user device, at 314. The rendering system can store (e.g., adatabase 116 as shown in FIG. 1 ) the report containing the recreatedevent, at 316.

In some implementations, the current subject matter can be configured tobe implemented in a system 700, as shown in FIG. 7 . The system 700 caninclude a processor 710, a memory 720, a storage device 730, and aninput/output device 740. Each of the components 710, 720, 730 and 740can be interconnected using a system bus 750. The processor 710 can beconfigured to process instructions for execution within the system 700.In some implementations, the processor 710 can be a single-threadedprocessor. In alternate implementations, the processor 710 can be amulti-threaded processor. The processor 710 can be further configured toprocess instructions stored in the memory 720 or on the storage device730, including receiving or sending information through the input/outputdevice 740. The memory 720 can store information within the system 700.In some implementations, the memory 720 can be a computer-readablemedium. In alternate implementations, the memory 720 can be a volatilememory unit. In yet some implementations, the memory 720 can be anon-volatile memory unit. The storage device 730 can be capable ofproviding mass storage for the system 700. In some implementations, thestorage device 730 can be a computer-readable medium. In alternateimplementations, the storage device 730 can be a floppy disk device, ahard disk device, an optical disk device, a tape device, non-volatilesolid state memory, or any other type of storage device. Theinput/output device 740 can be configured to provide input/outputoperations for the system 700. In some implementations, the input/outputdevice 740 can include a keyboard and/or pointing device. In alternateimplementations, the input/output device 740 can include a display unitfor displaying graphical user interfaces.

FIG. 8 illustrates an exemplary method 800, according to someimplementations of the current subject matter. The method 800 can beperformed by the system 100, as shown in FIG. 1 . At 802, a plurality ofdata can be received from a plurality of sources of information. Thedata can describe an event, where the data can have a different format.At 804, each received data can be converted into a predetermined format(which can be determined by the rendered system 102 as shown in FIG. 1 )and, once converted, the data can be combined. At 806, a reportdescribing a recreation of the event can be generated based on thecombined converted received data. The rendering system 102 can performconversion of data, processing of data and generation of the report(e.g., a vehicle accident report). At 808, the generated report can betransmitted for display on at least one user interface (e.g., userinterface of the devices 104, 106 as shown in FIG. 1 ).

In some implementations, the current subject matter can include one ormore of the following optional features. The plurality of sources caninclude a plurality of sensors communicatively coupled to the at leastone computing system (e.g., rendering system 102). The plurality ofsensors can detect and record information about the event.

In some implementations, the data can include at least one of thefollowing: a video data, an audio data, a text data, a photographicdata, and any combination thereof.

In some implementations, the generated report can be transmitted fordisplay using a first user interface associated with a first user device(e.g., user device 104) and for display using a second user interfaceassociated with a second user device (e.g., user device 106). The firstand second user devices can be communicatively coupled to the at leastone computing system using a network.

In some implementations, the method 800 can further include receivingchanges to the generated report from the second device, generating,based on the received changes, a new report and transmitting the newreport to the first user device and the second user device, receiving aconfirmation, from the second device, indicating that the new report hasno changes, and transmitting the confirmation to the first device.

In some implementations, the report can include at least one of thefollowing: a data describing the event, a video illustrating the event,an audio describing the event, an animation illustrating the event, anarrative textual data describing the event, and any combinationthereof.

In some implementations, the event can be a vehicular accident. In thatcase, the plurality of sensors can include at least one of thefollowing: a vehicle blackbox sensor, a mobile device, a vehicle onboardusage-based insurance enable device, and a vehicle onboard sensor. Thegenerated report can be transmitted to a claimant user device fordisplay on a user interface associated with the claimant user device,wherein the claimant user device is used to record data describing thevehicular accident. The claimant user device can be communicativelycoupled to the computing system for submission of at least one insuranceclaim as a result of the vehicular accident. A claims adjuster devicecan receive the generated report for processing of the insurance claim.

The systems and methods disclosed herein can be embodied in variousforms including, for example, a data processor, such as a computer thatalso includes a database, digital electronic circuitry, firmware,software, or in combinations of them. Moreover, the above-noted featuresand other aspects and principles of the present disclosedimplementations can be implemented in various environments. Suchenvironments and related applications can be specially constructed forperforming the various processes and operations according to thedisclosed implementations or they can include a general-purpose computeror computing platform selectively activated or reconfigured by code toprovide the necessary functionality. The processes disclosed herein arenot inherently related to any particular computer, network,architecture, environment, or other apparatus, and can be implemented bya suitable combination of hardware, software, and/or firmware. Forexample, various general-purpose machines can be used with programswritten in accordance with teachings of the disclosed implementations,or it can be more convenient to construct a specialized apparatus orsystem to perform the required methods and techniques.

The systems and methods disclosed herein can be implemented as acomputer program product, i.e., a computer program tangibly embodied inan information carrier, e.g., in a machine readable storage device or ina propagated signal, for execution by, or to control the operation of,data processing apparatus, e.g., a programmable processor, a computer,or multiple computers. A computer program can be written in any form ofprogramming language, including compiled or interpreted languages, andit can be deployed in any form, including as a stand-alone program or asa module, component, subroutine, or other unit suitable for use in acomputing environment. A computer program can be deployed to be executedon one computer or on multiple computers at one site or distributedacross multiple sites and interconnected by a communication network.

As used herein, the term “user” can refer to any entity including aperson or a computer.

Although ordinal numbers such as first, second, and the like can, insome situations, relate to an order; as used in this document ordinalnumbers do not necessarily imply an order. For example, ordinal numberscan be merely used to distinguish one item from another. For example, todistinguish a first event from a second event, but need not imply anychronological ordering or a fixed reference system (such that a firstevent in one paragraph of the description can be different from a firstevent in another paragraph of the description).

The foregoing description is intended to illustrate but not to limit thescope of the invention, which is defined by the scope of the appendedclaims. Other implementations are within the scope of the followingclaims.

These computer programs, which can also be referred to programs,software, software applications, applications, components, or code,include machine instructions for a programmable processor, and can beimplemented in a high-level procedural and/or object-orientedprogramming language, and/or in assembly/machine language. As usedherein, the term “machine-readable medium” refers to any computerprogram product, apparatus and/or device, such as for example magneticdiscs, optical disks, memory, and Programmable Logic Devices (PLDs),used to provide machine instructions and/or data to a programmableprocessor, including a machine-readable medium that receives machineinstructions as a machine-readable signal. The term “machine-readablesignal” refers to any signal used to provide machine instructions and/ordata to a programmable processor. The machine-readable medium can storesuch machine instructions non-transitorily, such as for example as woulda non-transient solid state memory or a magnetic hard drive or anyequivalent storage medium. The machine-readable medium can alternativelyor additionally store such machine instructions in a transient manner,such as for example as would a processor cache or other random accessmemory associated with one or more physical processor cores.

To provide for interaction with a user, the subject matter describedherein can be implemented on a computer having a display device, such asfor example a cathode ray tube (CRT) or a liquid crystal display (LCD)monitor for displaying information to the user and a keyboard and apointing device, such as for example a mouse or a trackball, by whichthe user can provide input to the computer. Other kinds of devices canbe used to provide for interaction with a user as well. For example,feedback provided to the user can be any form of sensory feedback, suchas for example visual feedback, auditory feedback, or tactile feedback;and input from the user can be received in any form, including, but notlimited to, acoustic, speech, or tactile input.

The subject matter described herein can be implemented in a computingsystem that includes a back-end component, such as for example one ormore data servers, or that includes a middleware component, such as forexample one or more application servers, or that includes a front-endcomponent, such as for example one or more client computers having agraphical user interface or a Web browser through which a user caninteract with an implementation of the subject matter described herein,or any combination of such back-end, middleware, or front-endcomponents. The components of the system can be interconnected by anyform or medium of digital data communication, such as for example acommunication network. Examples of communication networks include, butare not limited to, LAN, WAN, and the Internet.

The computing system can include clients and servers. A client andserver are generally, but not exclusively, remote from each other andtypically interact through a communication network. The relationship ofclient and server arises by virtue of computer programs running on therespective computers and having a client-server relationship to eachother.

The implementations set forth in the foregoing description do notrepresent all implementations consistent with the subject matterdescribed herein. Instead, they are merely some examples consistent withaspects related to the described subject matter. Although a fewvariations have been described in detail above, other modifications oradditions are possible. In particular, further features and/orvariations can be provided in addition to those set forth herein. Forexample, the implementations described above can be directed to variouscombinations and sub-combinations of the disclosed features and/orcombinations and sub-combinations of several further features disclosedabove. In addition, the logic flows depicted in the accompanying figuresand/or described herein do not necessarily require the particular ordershown, or sequential order, to achieve desirable results. Otherimplementations can be within the scope of the following claims.

What is claimed is:
 1. A method comprising: receiving data describing anevent from a plurality of sources; determining additional data is neededto generate a rendering of the event, the additional data providing aviewpoint from a mobile device of the event; generating an instructionfor presentation at the mobile device, the instruction directing a userto upload the additional data captured by the mobile device; receivingthe additional data from the mobile device; and generating the renderingof the event.
 2. The method of claim 1, wherein the plurality of sourcesinclude one or more of a sensor, the mobile device, and a third partysource.
 3. The method of claim 2, wherein the sensor includes one ormore of a speed sensor, a fuel sensor, a torque sensor, a camera, abrake sensor, a weather sensor, and a tire pressure sensor.
 4. Themethod of claim 1, wherein the data describing the event includes one ormore of video data, audio data, text data, location data, andphotographic data.
 5. The method of claim 1, wherein the additional dataincludes one or more of video data and audio data collected by themobile device.
 6. The method of claim 1, wherein the mobile device islocated in a vehicle involved in the event.
 7. The method of claim 1,wherein the event is a vehicular accident.
 8. A system comprising: atleast one processor; and a machine-readable medium storing instructionsthat, when executed by the at least one processor, cause the at leastone processor to perform operations comprising: receiving datadescribing an event from at least one source; determining additionaldata is needed to generate a visual representation of the event, theadditional data providing a viewpoint from a mobile device of the event;generating an instruction to cause the mobile device to direct a user toupload the additional data captured by the mobile device; receiving theadditional data from the mobile device; and generating the visualrepresentation of the event.
 9. The system of claim 8, wherein the atleast one source includes one or more of a sensor, the mobile device,and a third party source.
 10. The system of claim 9, wherein the sensorincludes one or more of a speed sensor, a fuel sensor, a torque sensor,a camera, a brake sensor, a weather sensor, and a tire pressure sensor.11. The system of claim 8, wherein the data describing the eventincludes one or more of video data, audio data, text data, locationdata, and photographic data.
 12. The system of claim 8, wherein theadditional data includes one or more of video data and audio datacollected by the mobile device.
 13. The system of claim 8, wherein themobile device is located in a vehicle involved in the event.
 14. Thesystem of claim 8, wherein the event is a traffic incident.
 15. One ormore non-transitory computer-readable media storing instructions that,when executed by at least one processor, cause the at least oneprocessor to perform operations comprising: receiving event data from atleast one source; determining additional data is needed to generate areport of an event, the additional data providing a viewpoint from amobile device of the event; generating an instruction to cause themobile device to direct a user to upload the additional data captured bythe mobile device; receiving the additional data from the mobile device;and generating the report of the event.
 16. The one or morenon-transitory computer-readable media of claim 15, wherein the at leastone source includes one or more of a sensor, the mobile device, and athird party source.
 17. The one or more non-transitory computer-readablemedia of claim 16, wherein the sensor includes one or more of a speedsensor, a fuel sensor, a torque sensor, a camera, a brake sensor, aweather sensor, and a tire pressure sensor.
 18. The one or morenon-transitory computer-readable media of claim 15, wherein the eventdata includes one or more of video data, audio data, text data, locationdata, and photographic data.
 19. The one or more non-transitorycomputer-readable media of claim 15, wherein the report includes avisual representation of the event.
 20. The one or more non-transitorycomputer-readable media of claim 15, wherein the additional dataincludes one or more of video data and audio data collected by themobile device.